嗨大家，我是 Debuguy。

今天要來聊一個實務上超重要的技巧：Partial Prompts。

先回顧一下：這個專案的初衷

還記得 Day 1 我們為什麼要做這個專案嗎？

「我想要一個能幫我解決 Issues 的 Slack Bot」

但到目前為止，我們都在講「怎麼讓 Slack Bot 變成 Chatbot」：

• 怎麼接收訊息
• 怎麼呼叫 LLM
• 怎麼回覆訊息

這些都只是基礎建設。真正的目標是：

Slack Bot (基礎) + 特定任務 Prompt = 解決 Issue 的助手

但如果把「Slack Bot 的基礎設定」和「解決 Issue 的邏輯」全部混在同一個 prompt 裡，就會有個大問題：

「其他團隊也想用，但他們不是要解決 Issue，而是要做客服、寫文件、分析數據...」

這時候就尷尬了：每個需求都要從頭寫一個完整的 prompt。

我想要的最終型態

理想中的部署方式

docker run -d \
  -v ./my-prompts:/app/prompts \
  -v ./my-mcp-config:/app/config \
  -e SLACK_BOT_TOKEN=xxx \
  debuguy/slack-ai-chatbot

使用者只要：

1. 拉我的 Docker Image
2. 掛載他們自己的 prompt 檔案
3. 掛載他們的 MCP 設定（如果需要工具）
4. 啟動！

不需要：

• ❌ 修改程式碼
• ❌ 重新編譯
• ❌ 學習我的專案架構
• ❌ 重複定義 Slack Bot 的基礎設定

為什麼需要 Partial Prompts？

假設沒有 partial，每個使用者都得寫：

# user_a_issue_solver.prompt
---
model: googleai/gemini-2.5-flash-lite
---
{{role "system"}}
## Your Role and Identity
- You are a helpful AI assistant operating as a Slack bot. 
- Your Slack ID is {{botUserId}}.
- You can help with questions...
(一大段 Slack Bot 的基礎設定)

## Your Mission: GitHub Issue Solver
(這才是使用者真正想定義的部分)

## Your Response Strategy
- You will receive messages from users...
(又是一大段 Slack 互動規則)

# user_b_customer_service.prompt
---
model: googleai/gemini-2.5-flash-lite
---
{{role "system"}}
## Your Role and Identity
- You are a helpful AI assistant operating as a Slack bot. 
- Your Slack ID is {{botUserId}}.
(又是同樣的一大段...)

## Your Mission: Customer Service
(使用者想定義的部分)

## Your Response Strategy
- You will receive messages from users...
(又是一大段 Slack 互動規則)

問題來了：

1. 重複勞動：每個人都要重寫 Slack Bot 的基礎設定
2. 容易出錯：使用者可能漏寫某些重要規則
3. 難以更新：如果我改進了 Slack 互動邏輯，使用者的 prompt 無法受益
4. 違背初衷：我想提供的是「開箱即用的 Slack AI Bot 框架」，不是讓大家重造輪子

Partial Prompts：把框架和業務邏輯分離

架構設計圖

┌─────────────────────────────────────────┐
│   Docker Image (我提供的框架層)           │
│                                         │
│   prompts/partials/                     │
│   ├── _chatbot_define.prompt            │
│   └── _chatbot_response.prompt          │
└─────────────────────────────────────────┘
                    ↓ 引用
┌─────────────────────────────────────────┐
│   User Volume (使用者的業務層)            │
│                                         │
│   ├── issue_solver.prompt               │
│   ├── customer_service.prompt           │
│   └── data_analyst.prompt               │
└─────────────────────────────────────────┘

我的設計：框架層 + 業務層

框架層（內建在 Docker Image）：

prompts/
  partials/
    _chatbot_define.prompt      # Slack Bot 角色定義
    _chatbot_response.prompt    # Slack 互動規則

業務層（使用者掛載）：

# issue_solver.prompt (使用者自己的檔案)
---
model: googleai/gemini-2.5-flash-lite
config:
  temperature: 0.3
---
{{role "system"}}
{{>_chatbot_define}}      # 引用框架提供的基礎

## Your Mission: GitHub Issue Solver
You are specialized in analyzing GitHub issues and providing solutions.

### Your Capabilities
- Understand technical problems from issue descriptions
- Suggest debugging approaches
- Recommend potential fixes
- Ask clarifying questions when needed

### Your Workflow
1. Carefully read the issue description
2. Identify the core problem
3. Consider edge cases
4. Provide actionable solutions

{{>_chatbot_response}}    # 引用框架提供的互動規則

看到差異了嗎？

使用者只需要寫：

• 模型選擇和參數（如果要客製化）
• 引用框架 partial：{{>_chatbot_define}} 和 {{>_chatbot_response}}
• 專注在業務邏輯：「這個 Bot 要做什麼」

實際使用方式

# 使用者的專案目錄
my-slack-bot/
  prompts/
    issue_solver.prompt        # 只寫業務邏輯
  config/
    mcp-config.json            # 如果需要工具
  .env                         # Bot token 等

# 啟動
docker run -d \
  -v $(pwd)/prompts:/app/prompts \
  -v $(pwd)/config:/app/config \
  --env-file .env \
  debuguy/slack-ai-bot

Bot 啟動時：

1. 讀取使用者的 issue_solver.prompt
2. 遇到 {{>_chatbot_define}} → 去 Docker Image 內建的 partials/ 找
3. 組合成完整的 prompt
4. 開始運作！

這樣設計的好處

1. 降低使用門檻

使用者不需要：

• ❌ 研究 Slack API 的互動細節
• ❌ 了解怎麼處理 thread
• ❌ 知道怎麼 mention user
• ❌ 擔心 Slack 訊息格式

只需要專注在：

• ✅ 我的 Bot 要做什麼
• ✅ 它應該有什麼個性
• ✅ 業務邏輯是什麼

2. 框架可以持續進化

假設我發現 Slack 互動有更好的處理方式：

# _chatbot_response.prompt
## Your Response Strategy
- You will receive messages from users in a Slack channel.
+ - Always check if the message is in a thread before replying.
+ - If in a thread, maintain context awareness.

更新後：

• 我發布新版 Docker Image
• 使用者只要 docker pull 更新
• 所有用這個框架的 Bot 都自動受益
• 使用者的業務 prompt 完全不用改

3. 多情境部署變簡單

公司有很多不同團隊，想要部署不同用途的 Bot：

# Engineering Team
docker run -d \
  -v ./prompts/issue_solver.prompt:/app/prompts/main.prompt \
  debuguy/slack-ai-bot

# Customer Support Team  
docker run -d \
  -v ./prompts/customer_service.prompt:/app/prompts/main.prompt \
  debuguy/slack-ai-bot

# Data Team
docker run -d \
  -v ./prompts/data_analyst.prompt:/app/prompts/main.prompt \
  debuguy/slack-ai-bot

同一個 Docker Image，三種用途，只是掛載不同的業務 prompt！

實際的檔案結構

Docker Image 內建（框架層）

/app/
  prompts/
    partials/
      _chatbot_define.prompt       # 角色定義
      _chatbot_response.prompt     # 回應策略
  src/
    # 程式碼
  config/
    # 預設設定

使用者掛載（業務層）

# 直接指定檔案
-v ./issue_solver.prompt:/app/prompts/main.prompt

# 同時掛載 MCP 工具配置
-v ./mcp-config.json:/app/config/mcp-config.json

延伸思考：MCP 也是類似概念

其實 MCP (Model Context Protocol) 也是同樣的思路：

// 使用者掛載自己的 MCP 配置
{
  "mcpServers": {
    "github": { /* GitHub API */ },
    "jira": { /* Jira API */ },
    "slack": { /* 進階 Slack 操作 */ }
  }
}

最終效果：

基礎框架 (Slack Bot + 基礎 MCP)
  + 
使用者配置 (業務 Prompt + 專用 MCP)
  =
完全客製化的 AI Assistant

結語

Partial Prompts 不只是「避免重複」這麼簡單，更重要的是：

讓專案從「單一用途的工具」變成「可擴展的框架」

透過把「平台層」和「業務層」分離：

• 框架開發者可以專注優化平台能力
• 使用者可以專注在業務邏輯
• 整個生態可以更健康地成長

這就是為什麼我要把 _chatbot_define 和 _chatbot_response 抽出來的真正原因：不是為了現在，而是為了未來的擴展性。

當有一天，有人說「欸，你這個 Slack Bot 框架不錯，我拿去做 XXX 用途了」，那就代表這個設計達到目的了。

完整的原始碼在這裡

AI 的發展變化很快，目前這個想法以及專案也還在實驗中。但也許透過這個過程大家可以有一些經驗和想法互相交流，歡迎大家追蹤這個系列。

也歡迎追蹤我的 Threads @debuguy.dev